前言

過去 Package Management 通常在專案類型與小型團隊比較少討論到，必須具有一定規模的產品、組織或平台服務才會有 Management。其主要原因在於隨著軟體規模越來越大，小型開發團隊變成多個團隊、Codebase 日益增長難以維護，團隊開始尋求元件化方式以達到有效率的分享與管理元件，才會開始發展獨自 Package Managemet。

Package Management 並非不適用於專案類型與小型團隊。若開發初期導入 Package Management 觀念的團隊，通常產品與維運阻礙會較少。

Package Management

Code dependency 與 Package management

在開始談 Package Management 之前，我們先討論一下程式碼相依。在開發團隊中，將共用功能抽出轉換成元件 (JAR, DLL...等)，提供團隊重複使用是很常見的事情，但傳統將這些編譯過的元件放入在專案中做為參考卻發生許多意想不到突發狀況，導致團隊開發效率低弱，舉例來說....

1. DLL 位置放在 output 然後提供其他專案參考，IDE 執行 Clean 時的時候一併把 DLL 清掉。團隊成員要知道編譯專案先後順序。
2. 完全不清楚 DLL 版本，每次要使用前要打開檔案或反組譯後才能知道版本，甚至要看原始碼才能知道是否能用
3. 沒有統一的管理方式，不同團隊要找過去使用過的套件需要考古或靠關係，或一堆重複元件
4. 將打包好的元件推送至版本管理，除了讓 Git 變得肥大沒效率，也可能造成合併衝突、覆蓋，導致軟體相依性更混亂
   

基本上現代開發人員多少接知道 Package 功能，將交付的內容進行包裝，其中包含編譯過的程式(Assemblies)、
Symbol 或其他交付檔案。Package 獨立於原專案編譯或其他方式將檔案進行包裝，儘管可以參考其他專案，讓 Assemblies 與 Package 保持同步。

Package 元件化可以解決參考 Binaries 挑戰、簡化可重複元件安裝與維護，且有效率的相依處理流程。主要原因在於它有標準一致的標準，以相同格式進行發布，每個版本一目了然。

 
講到此許多讀者可能覺得很抽象，但提到常見 Package 管理工具，你一定會覺得非常熟悉。常見 Package 管理工具如下：

什麼是 Azure Artifact

過去在到各企業擔任顧問時，團隊詢問 Package 管理工具的機會不多，主要原因在於多數人會認為有公開的 Package Management 服務，為何還要自建 Package 管理工具？多數諮詢主要原因如下：

1. 私有託管且需要身分驗證需求
2. 需要與既有 DevOps Tool 整合 (如：不因外部功能套件升級而導致 CI/CD 中斷)
3. 資安掃描需求確保套件安全

遇到想要知道的團隊，多數是有一定規模、紀律與深度產品的團隊。

Azure Artifact 是 Azure DevOps 功能之一，除了使用 Package 方式讓組織成員共享與重複使用程式碼，也提供私有、託管與身分驗證 Feeds 方式讓您分享、搜尋與維護 Package 與相依項目。可以與既有 Build Pipeline 與 Release Pipeline 無縫整合，也能將外部開源套件引入企業，降低團隊維護負擔。

目前 Azure Artifact 支援 NuGet、NPM、Maven 與 Python。其中每一個 Package 版本為獨一無二且無法更動，但支援 PreRelease 與 Final，確保有效的版本管理。除此之外，團隊可以發布 Symbol 以協助偵錯，可以透過 Pipeline 內建 Task 執行。目前 Artifact 可以設定的使用範圍為公開、組織與專案